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Abstract 


The Path Computation Element Communication Protocol (PCEP) defines 
the mechanisms for the communication between a Path Computation 
Client (PCC) and a Path Computation Element (PCE), or among PCEs. 
This document describes PCEPS -- the usage of Transport Layer 
Security (TLS) to provide a secure transport for PCEP. The 
additional security mechanisms are provided by the transport protocol 
supporting PCEP; therefore, they do not affect the flexibility and 
extensibility of PCEP. 


This document updates RFC 5440 in regards to the PCEP initialization 
phase procedures. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8253. 
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Les 


Introduction 


The Path Computation Element Communication Protocol (PCEP) [RFC5440] 
defines the mechanisms for the communication between a Path 
Computation Client (PCC) and a Path Computation Element (PCE), or 
between two PCEs. These interactions include requests and replies 
that can be critical for a sustainable network operation and adequate 
resource allocation; therefore, appropriate security becomes a key 
element in the PCE infrastructure. As the applications of the PCE 
framework evolve and more complex service patterns emerge, the 
definition of a secure mode of operation becomes more relevant. 


The Security Considerations section of [RFC5440] analyzes the 
potential threats to PCEP and their consequences; it also discusses 
several mechanisms for protecting PCEP against security attacks, 
without making a specific recommendation on a particular one or 
defining their application in depth. Moreover, [RFC6952] states the 
importance of ensuring PCEP communication confidentiality, especially 
when PCEP communication endpoints do not reside in the same 
Autonomous System (AS), as the interception of PCEP messages could 
leak sensitive information related to computed paths and resources. 


Transport Layer Security (TLS) [RFC5246] is one of the solutions that 
seems most adequate among those mentioned in these documents, as it 
provides support for peer authentication, message encryption, and 
integrity. TLS provides well-known mechanisms to support key 
configuration and exchange, as well as means to perform security 
checks on the results of PCE Discovery (PCED) procedures via the 
Interior Gateway Protocol (IGP) [RFC5088] [RFC5089]. 


This document describes a security container for the transport of 
PCEP messages; therefore, it does not affect the flexibility and 
extensibility of PCEP. 


This document describes how to apply TLS to secure interactions with 
PCE, including initiation of the TLS procedures, the TLS handshake 
mechanism, the TLS methods for peer authentication, the applicable 
TLS ciphersuites for data exchange, and the handling of errors in the 
security checks. In the rest of this document, we refer to this 
usage of TLS to provide a secure transport for PCEP as "PCEPS". 


Within this document, PCEP communications are described through a 
PCC-PCE relationship. The PCE architecture also supports PCE-PCE 
communication; this is achieved by requesting the PCE to fill the 
role of a PCC, as usual. Thus, in this document, the PCC refers toa 
PCC or a PCE initiating the PCEP session and acting as a client. 
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Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Applying PCEPS 
1. Overview 

The steps involved in establishing a PCEPS session are as follows: 
1. Establishment of a TCP connection. 


2. Initiation of the TLS procedures by the StartTLS message from PCE 
to PCC and from PCC to PCE. 


3. Negotiation and establishment of a TLS connection. 
4. Start exchange of PCEP messages as per [RFC5440]. 


This document uses the standard StartTLS procedure in PCEP instead of 
using a different port for the secured session. This is done to 
avoid requesting allocation of another port number for PCEPS. The 
StartTLS procedure makes more efficient use of scarce port numbers 
and allows simpler configuration of PCEP. 


Implementations SHOULD follow the best practices and recommendations 
for using TLS, as per [RFC7525]. 


It should be noted that this procedure updates what is defined in 
Sections 4.2.1 and 6.7 of [RFC5440] regarding the initialization 
phase and the processing of messages prior to the Open message. The 
details of processing, including backward compatibility, are 
discussed in the following sections. 


-2. Initiating TLS Procedures 


Since PCEP can operate either with or without TLS, it is necessary 
for a PCEP speaker to indicate whether it wants to set up a TLS 
connection or not. For this purpose, this document specifies a new 
PCEP message called "StartTLS". Thus, the PCEP session is secured 
via TLS from the start, before the exchange of any other PCEP message 
(including the Open message). This document thus updates [RFC5440], 
which requires the Open message to be the first PCEP message that is 
exchanged. In the case of a PCEP session using TLS, the StartTLS 
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message will be sent first. Also, a PCEP speaker that supports PCEPS 
MUST NOT start the OpenWait timer after the TCP establishment; 
instead, it starts a StartTLSWait timer as described in Section 3.3. 


The PCEP speaker MAY discover that the PCEP peer supports PCEPS or 
can be preconfigured to use PCEPS for a given peer (see Section 4 for 
more details). An existing PCEP session cannot be secured via TLS; 
the session MUST be closed and re-established with TLS as per the 
procedure described in this document. 


The StartTLS message is a PCEP message sent by a PCC to a PCE and by 
a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 
PCC initiates the use of TLS by sending a StartTLS message. The PCE 
agrees to the use of TLS by responding with its own StartTLS message. 
If the PCE is configured to only support TLS, it may send the 
StartTLS message immediately upon TCP connection establishment; 
otherwise, it MUST wait to see if the PCC’s first message is an Open 
or a StartTLS message. The TLS negotiation and establishment 
procedures are triggered once the PCEP speaker has sent and received 
the StartTLS message. The Message-Type field of the PCEP common 
header for the StartTLS message is set to 13. 


Once the TCP connection has been successfully established, the first 

message sent by the PCC to the PCE and by the PCE to the PCC MUST be 

a StartTLS message for PCEPS. Note that this is a significant change 
from [RFC5440], where the first PCEP message is the Open message. 


A PCEP speaker receiving a StartTLS message, after any other PCEP 
exchange has taken place (by receiving or sending any other messages 
from either side), MUST treat it as an unexpected message and reply 
with a PCEP Error (PCErr) message with Error-Type set to 25 (PCEP 
StartTLS failure) and Error-value set to 1 (Reception of StartTLS 
after any PCEP exchange), and it MUST close the TCP connection. 


Any message received prior to the StartTLS or Open message MUST 
trigger a protocol error condition causing a PCErr message to be sent 
with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set 
to 2 (Reception of any other message apart from StartTLS, Open, or 
PCErr), and it MUST close the TCP connection. 


If the PCEP speaker that does not support PCEPS receives a StartTLS 
message, it will behave according to the existing error mechanism 


described in Section 6.2 of [RFC5440] (if the message is received 
prior to an Open message) or Section 6.9 of [RFC5440] (if an unknown 
message is received). See Section 5 for more details. 
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If the PCEP speaker that only supports PCEPS connections (as a local 
policy) receives an Open message, it MUST treat it as an unexpected 
message and reply with a PCErr message with Error-Type set to 1 (PCEP 
session establishment failure) and Error-value set to 1 (reception of 
an invalid Open message or a non Open message), and it MUST close the 
TCP connection. 


If a PCC supports PCEPS connections and allows non-PCEPS connections 
(as a local policy), it MUST first try to establish PCEPS by sending 
a StartTLS message, and in case it receives a PCErr message from the 
PCE, it MAY retry to establish a connection without PCEPS by sending 
an Open message. If a PCE supports PCEPS connections and allows 
non-PCEPS connections (as a local policy), it MUST wait to respond 
after TCP establishment, based on the message received from the PCC. 
In case of a StartTLS message, the PCE MUST respond by sending a 
StartTLS message and moving to TLS establishment procedures as 


described in this document. In case of an Open message, the PCE MUST 
respond with an Open message and move to the PCEP session 
establishment procedure as per [RFC5440]. If a PCE supports PCEPS 


connections only (as a local policy), it MAY send a StartTLS message 
to the PCC without waiting to receive a StartTLS message from the 
PCC. 


If a PCEP speaker that is unwilling or unable to negotiate TLS 
receives a StartTLS message, it MUST return a PCErr message (in the 
clear) with Error-Type set to 25 (PCEP StartTLS failure) and Error- 
value set to: 


o 3 (Failure, connection without TLS is not possible) if it is not 
willing to exchange PCEP messages without the solicited TLS 
connection, and it MUST close the TCP session. 


o 4 (Failure, connection without TLS is possible) if it is willing 
to exchange PCEP messages without the solicited TLS connection, 
and it MUST close the TCP session. The receiver MAY choose to 
attempt to re-establish the PCEP session without TLS next. 
Re-establishing the PCEP session without TLS SHOULD be limited to 
only one attempt. 


If the PCEP speaker supports PCEPS and can establish a TLS 
connection, it MUST start the TLS connection negotiation and 
establishment steps described in Section 3.4 before the PCEP 
initialization procedure (see Section 4.2.1 of [RFC5440]). 


After the exchange of StartTLS messages, if the TLS negotiation fails 
for some reason (e.g., the required mechanisms for certificate 
revocation checking are not available), both peers MUST immediately 
close the connection. 
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A PCEP speaker that does not support PCEPS sends the Open message 
directly, as per [RFC5440]. A PCEP speaker that supports PCEPS, but 
has learned in the last exchange the peer’s willingness to 
re-establish the session without TLS, MAY send the Open message 
directly, as per [RFC5440]. Re-establishing the PCEP session without 
TLS SHOULD be limited to only one attempt. 


Given the asymmetric nature of TLS for connection establishment, it 
is relevant to identify the roles of each of the PCEP peers in it. 
The PCC SHALL act as the TLS client, and the PCE SHALL act as the TLS 
server as per [RFC5246]. 


As per the recommendation from [RFC7525] to avoid downgrade attacks, 
PCEP peers that support PCEPS SHOULD default to strict TLS 
configuration, i.e., not allowing non-TLS PCEP sessions to be 
established. PCEPS implementations MAY provide an option to allow 
the operator to manually override strict TLS configuration and allow 


unsecured connections. Execution of this override SHOULD trigger a 
warning about the security implications of permitting unsecured 
connections. 


3.3. The StartTLS Message 


The StartTLS message is used to initiate the TLS procedure for a 
PCEPS session between the PCEP peers. A PCEP speaker sends the 
StartTLS message to request negotiation and establishment of a TLS 
connection for PCEP. On receiving a StartTLS message from the PCEP 
peer (i.e., when the PCEP speaker has sent and received the StartTLS 
message), it is ready to start the negotiation and establishment of 
TLS and move to the steps described in Section 3.4. 


The collision resolution procedures described in [RFC5440] for the 
exchange of Open messages MUST be applied by the PCEP peers during 
the exchange of StartTLS messages. 


The format of a StartTLS message is as follows: 
<StartTLS Message>::= <Common Header> 


The StartTLS message MUST contain only the PCEP common header with 
the Message-Type field set to 13. 


Once the TCP connection has been successfully established, the PCEP 
speaker MUST start a timer called the "StartTLSWait timer". After 
the expiration of this timer, if neither the StartTLS message nor a 
PCErr/Open message (in case of failure and PCEPS not being supported 
by the peer, respectively) has been received, the PCEP speaker MUST 
send a PCErr message with Error-Type set to 25 (PCEP StartTLS 
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failure) and Error-value set to 5 (No StartTLS message (nor PCErr/ 
Open) before StartTLSWait timer expiry), and it MUST release the TCP 
connection. A RECOMMENDED value for the StartTLSWait timer is 60 
seconds. The value of the StartTLSWait timer MUST NOT be less than 
that of the OpenWait timer. 


The following figures illustrate the various interactions between a 
PCC and a PCE, based on the support for the PCEPS capability, during 
the PCEP session initialization. 


+++ +++ 
|pec | | PCE | 
+++ +++ 
| | 
| StartTLS | 
| msg | 
| |: StartTLS || 
| \ msg | 
| \ oo =4-=---=- | 
| \/ | 
/\ 
/ -------- > 
| / | 
|<------ | 
(TL ee ess] 
|:::::Establishment::: | 
lssstss2PCEPrrssrssise| 
| | 


Figure 1: Both PCEP speakers support PCEPS (strict) 
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+++ +++ 
|Pcc | |PCE | 
+++ +++ 
| | 
| StartTLS | 
| msg | 
| \ StartTLS | 
O 
Ni alaba 
| \/ | 
| /\ | 
| / -------- >| 
| / | 
|<------ | 
ricicciiiiiTLS::::::::2:| TLS Establishment 
cien Failure; both 


| peers close 
the session 


Figure 2: Both PCEP speakers support PCEPS (strict) but cannot 
establish TLS 
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+++ +++ 
|Pcc | |PCE | 
+-+-+ +-+-+ 
| | Does not support 
| StartTLS | PCEPS and thus 
| msg | sends Open 
| \ Open | 
\ msg 
| ea | 
| \/ | 
| /\ | 
| bY aaa ee >| 
| / | 
|<------ | 
Sores Sl SSeS essere | Send Error 
| PCErr | Type=1,Value=1 
| | (non-Open message 
| <-------------------- | received) 
| Close 


| 
ee See 
//////re-establish///// 
Send Open | Open 
this time | msg 


| | 
| | 
| Po >| 
| | 
| | 


Figure 3: PCE does not support connection with PCEPS, whereas PCC 
supports connection with or without PCEPS 
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PCE waits 

for PCC and 
responds with 
E TST sS sss Start TLS 


Figure 4: Both PCEP speakers support connection with or without PCEPS 


PCE waits 
for PCC 


E a Send Error 

| | Type=25,Value=3 

| | (Failure, connection 
|<-------------------- | without TLS is not 
| Close | possible) 


Figure 5: Both PCEP speakers support connection with or without 
PCEPS, but PCE cannot start TLS negotiation 
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+++ +++ 

|Pcc | |PCE | 

+-+-+ +++ 
| | 
| Open | 
| msg | PCE waits 
|-------------------- >| for PCC and 
| Open | responds with 
KISSES SS ESAS Open 


Figure 6: PCE supports connection with or without PCEPS, whereas PCC 


3.4. 


does not support connection with PCEPS 


TLS Connection Establishment 


Once the establishment of TLS has been agreed upon by the PCEP peers, 
the connection establishment SHALL follow the following steps: 


Le 


Lopez, 


Immediately negotiate a TLS session according to [RFC5246]. The 
following restrictions apply: 


* 


Support for TLS v1.2 [RFC5246] or later is REQUIRED. 


Support for certificate-based mutual authentication is 
REQUIRED. 


Negotiation of a ciphersuite providing for integrity 
protection is REQUIRED. 


Negotiation of a ciphersuite providing for confidentiality is 
RECOMMENDED. 


Support for and negotiation of compression is OPTIONAL. 


PCEPS implementations MUST, at a minimum, support negotiation 
of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460] and 
SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as 
well. Implementations SHOULD support the NIST P-256 
(secp256r1) curve [RFC4492]. In addition, PCEPS 
implementations MUST support negotiation of the 
mandatory-to-implement ciphersuites required by the versions 
of TLS that they support from TLS 1.3 onwards. 
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Peer authentication can be performed in any of the following two 
REQUIRED operation models: 


* TLS with X.509 certificates using Public-Key Infrastructure 
Exchange (PKIX) trust models: 


+ 


Implementations MUST allow the configuration of a list of 
trusted Certification Authorities (CAs) for incoming 
connections. 


Certificate validation MUST include the verification rules 
as per [RFC5280]. 


PCEPS implementations SHOULD incorporate revocation methods 
(Certificate Revocation List (CRL) downloading, Online 
Certificate Status Protocol (OCSP), etc.) according to the 
trusted CA policies. 


Implementations SHOULD indicate their trusted CAs. For TLS 
1.2, this is done using "certificate_authorities" on the 
server side (see Section 7.4.4 of [RFC5246]) and the 
"TrustedAuthorities" extension on the client side (see 
Section 6 of [RFC6066]). 


Implementations MUST follow the rules and guidelines for 
peer validation as defined in [RFC6125]. If an expected 
DNS name or IP address for the peer is configured, then the 
implementations MUST check them against the values in the 
presented certificate. The DNS names and the IP addresses 
can be contained in the Common Name Identifier (CN-ID) 
[RFC6125] or the subjectAltName entries. For verification, 
only one of these entries is considered. The following 
precedence applies: for DNS name validation, DNS-ID 
[RFC6125] has precedence over CN-ID, and for IP address 
validation, subjectAltName:iPAddr has precedence over 
CN-ID. 


Implementations MAY allow the configuration of a set of 
additional properties of the certificate to check for a 
peer’s authorization to communicate (e.g., a set of allowed 
values in URI-ID [RFC6125] or a set of allowed X.509 v3 
Certificate Policies). The definitions of these properties 
are out of scope of this document. 


* TLS with X.509 certificates using certificate fingerprints: 
Implementations MUST allow the configuration of a list of 
certificates that are trusted to identify peers, identified 
via the fingerprint of certificate octets encoded by the 
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Distinguished Encoding Rules (DER). Implementations MUST 
support SHA-256 as defined by [SHS] as the hash algorithm for 
the fingerprint, but a later revision may demand support for a 
stronger hash function. 


3. Start exchanging PCEP messages. 


* Once the TLS connection has been successfully established, the 
PCEP speaker MUST start the OpenWait timer [RFC5440]; after 
the expiration of this timer, if no Open message has been 
received, the PCEP speaker sends a PCErr message and releases 
the TCP/TLS connection. 


3.5. Peer Identity 


Depending on the peer authentication method in use, PCEPS supports 
different operation modes to establish a peer’s identity and whether 
it is entitled to perform requests or can be considered authoritative 
in its replies. PCEPS implementations SHOULD provide mechanisms for 
associating peer identities with different levels of access and/or 
authoritativeness, and they MUST provide a mechanism for establishing 
a default level for properly identified peers. Any connection 
established with a peer that cannot be properly identified SHALL be 
terminated before any PCEP exchange takes place. 


In TLS X.509 mode using fingerprints, a peer is uniquely identified 
by the fingerprint of the presented certificate. 


There are numerous trust models in PKIX environments, and it is 
beyond the scope of this document to define how a particular 
deployment determines whether a peer is trustworthy. Implementations 
that want to support a wide variety of trust models should expose as 
many details of the presented certificate to the administrator as 
possible so that the trust model can be implemented by the 
administrator. At least the following parameters of the X.509 
certificate SHOULD be exposed: 

o Peer’s IP Address 

o Peer’s Fully Qualified Domain Name (FQDN) 

o Certificate Fingerprint 

o Issuer 


o Subject 


o All X.509 v3 Extended Key Usage 
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o All X.509 v3 Subject Alternative Name 
o All X.509 v3 Certificate Policies 


Note that the remote IP address used for the TCP session 
establishment is also exposed. 


[RFC8232] specifies a Speaker Entity Identifier TLV 
(SPEAKER-ENTITY-ID) as an optional TLV that is included in the OPEN 
object. It contains a unique identifier for the node that does not 
change during the lifetime of the PCEP speaker. An implementation 
would thus expose the speaker entity identifier as part of the X.509 
v3 certificate’s subjectAltName:otherName, so that an implementation 
could use this identifier for the peer identification trust model. 


In addition, a PCC MAY apply the procedures described in "DNS-Based 


Authentication of Named Entities (DANE)" [RFC6698] to verify its peer 
identity when using DNS discovery. See Section 4.1 for further 
details. 


3.6. Connection Establishment Failure 


In case the initial TLS negotiation or the peer identity check fails, 
according to the procedures listed in this document, both peers MUST 
immediately close the connection. 


The initiator SHOULD follow the procedure listed in [RFC5440] to 
retry session setup as per the exponential back-off session 
establishment retry procedure. 


4. Discovery Mechanisms 


This document does not specify any discovery mechanism for support of 
PCEPS. [PCE-DISCOVERY-PCEPS-SUPPORT] and [PCE-DISCOVERY-DNS] make 
the following proposals: 


o A PCE can advertise its capability to support PCEPS using the 
IGP’s advertisement mechanism of the PCED information. The 
PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise PCE 
capabilities. It is present within the PCED sub-TLV carried by 
OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description 
and processing rules for this sub-TLV when carried within OSPF and 
IS-IS, respectively. PCE capability bits are defined in 
[RFC5088]. A new capability flag bit for the PCE-CAP-FLAGS 
sub-TLV that can be announced as an attribute to distribute PCEP 
security support information is proposed in 
[PCE-DISCOVERY-PCEPS-SUPPORT]. 
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o A PCE can advertise its capability to support PCEPS using DNS 
[PCE-DISCOVERY-DNS] by identifying the support of TLS. 


4.1. DANE Applicability 


DANE [RFC6698] defines a secure method to associate the certificate 
that is obtained from a TLS server with a domain name using DNS, 
i.e., using the TLSA DNS resource record (RR) to associate a TLS 
server certificate or public key with the domain name where the 
record is found, thus forming a "TLSA certificate association". The 
DNS information needs to be protected by DNS Security (DNSSEC). A 
PCC willing to apply DANE to verify server identity MUST conform to 
the rules defined in Section 4 of [RFC6698]. The implementation MUST 
support service certificate constraint (TLSA certificate usages type 
1) with Matching type 1 (SHA2-256) as described in [RFC6698] and 
[RFC7671]. The server’s domain name must be authorized separately, 
as TLSA does not provide any useful authorization guarantees. 


5. Backward Compatibility 


The procedures described in this document define a security container 
for the transport of PCEP requests and replies carried by a TLS 
connection initiated by means of a specific extended message 
(StartTLS) that does not interfere with PCEP speaker implementations 
not supporting it. 


A PCC that does not support PCEPS will send an Open message as the 
first message on TCP establishment. A PCE that only supports PCEPS 
will send a StartTLS message on TCP establishment. The PCC would 
consider the received StartTLS message as an error and behave 
according to the existing error mechanism of [RFC5440], i.e., it 
would send a PCErr message with Error-Type 1 (PCEP session 
establishment failure) and Error-value 1 (reception of an invalid 
Open message or a non Open message) and close the session. 


A PCC that support PCEPS will send a StartTLS message as the first 
message on TCP establishment. A PCE that does not support PCEPS 
would consider receiving a StartTLS message as an error, respond with 
a PCErr message with Error-Type 1 (PCEP session establishment 
failure) and Error-value 1 (reception of an invalid Open message or a 
non Open message), and close the session. 


If a StartTLS message is received at any other time by a PCEP speaker 
that does not implement PCEPS, it would consider it as an unknown 
message and would behave according to the existing error mechanism of 
[RFC5440], i.e., it would send a PCErr message with Error-Type 2 
(Capability not supported) and close the session. 
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An existing PCEP session cannot be upgraded to PCEPS; the session 
needs to be terminated and re-established as per the procedure 
described in this document. During the incremental upgrade, the PCEP 
speaker SHOULD allow session establishment with and without TLS. 

Once both PCEP speakers are upgraded to support PCEPS, the PCEP 
session is re-established with TLS; otherwise, a PCEP session without 
TLS is set up. A redundant PCE MAY also be used during the 
incremental deployment to take over the PCE undergoing upgrade. Once 
the upgrade is completed, support for the unsecured version SHOULD be 
removed. 


A PCE that accepts connections with or without PCEPS would respond 
based on the message received from the PCC. A PCC that supports 
connection with or without PCEPS would first attempt to connect with 
PCEPS, and in case of error, it MAY retry to establish connection 
without PCEPS. For successful TLS operations with PCEP, both PCEP 
peers in the network would need to be upgraded to support this 
document. 


Note that a PCEP implementation that supports PCEPS would respond 
with a PCErr message with Error-Type set to 25 (PCEP StartTLS 
failure) and Error-value set to 2 (Reception of any other message 
apart from StartTLS, Open, or PCErr) if any other message is sent 
before a StartTLS or Open message. If the sender of the invalid 
message is a PCEP implementation that does not support PCEPS, it will 
not be able to understand this error. A PCEPS implementation could 
also send the PCErr message as per [RFC5440] with Error-Type 1 (PCEP 
session establishment failure) and Error-value 1 (reception of an 
invalid Open message or a non Open message) before closing the 
session. 


6. IANA Considerations 
6.1. New PCEP Message 
The following new message type has been allocated within the "PCEP 
Messages" sub-registry of the "Path Computation Element Protocol 
(PCEP) Numbers" registry: 
Value Description Reference 


1:38 StartTLS This document 
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6. 


7. 


New Error-Values 


The following new error types and error values have been allocated 


within the "PCEP-ERROR Object Error Types and Values" sub-registry of 


the "Path Computation Element Protocol (PCEP) Numbers" registry: 


Error-Type Meaning Error-value Reference 
25 PCEP StartTLS 0: Unassigned This document 
failure 
1: Reception of This document 


StartTLS after 
any PCEP exchange 


2: Reception of This document 
any other message 

apart from StartTLS, 

Open, or PCErr 


3: Failure, connection This document 
without TLS is not 
possible 


4: Failure, connection This document 
without TLS is 
possible 


5: No StartTLS message This document 
(nor PCErr/Open) 

before StartTLSWait 

timer expiry 


Security Considerations 


While the application of TLS satisfies the requirement on 
confidentiality as well as fine-grained, policy-based peer 
authentication, there are security threats that it cannot address. 
It may be advisable to apply additional protection measures, in 
particular in what relates to attacks specifically addressed to 
forging the TCP connection underpinning TLS, especially in the case 


of long-lived connections. One of these measures is the application 
of the TCP Authentication Option (TCP-AO) [RFC5925], which is fully 
compatible with and deemed as complementary to TLS. The mechanisms 


to configure the requirements to use TCP-AO and other lower-layer 
protection measures with a particular peer are outside the scope of 
this document. 
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Since computational resources required by the TLS handshake and 
ciphersuite are higher than unencrypted TCP, clients connecting to a 
PCEPS server can more easily create high-load conditions, anda 
malicious client might create a denial-of-service attack more easily. 


Some TLS ciphersuites only provide integrity validation of their 
payload and provide no encryption; such ciphersuites SHOULD NOT be 
used by default. Administrators MAY allow the usage of these 
ciphersuites after careful weighting of the risk of relevant internal 
data leakage that can occur in such a case, as explicitly stated by 
[RFC6952]. 


When using certificate fingerprints to identify PCEPS peers, any two 
certificates that produce the same hash value will be considered the 
same peer. Therefore, it is important to make sure that the hash 
function used is cryptographically uncompromised, so that attackers 
are very unlikely to be able to produce a hash collision with a 
certificate of their choice. This document mandates support for 
SHA-256 as defined by [SHS], but a later revision may demand support 
for stronger functions if suitable attacks on it are known. 


PCEPS implementations that continue to accept connections without TLS 
are susceptible to downgrade attacks as described in [RFC7457]. An 
attacker could attempt to remove the use of StartTLS messages that 
request the use of TLS as it pass on the wire in clear and could also 
attempt to inject a PCErr message that suggests attempting PCEP 
connection without TLS. 


The guidance given in [RFC7525] SHOULD be followed to avoid attacks 
on TLS. 


8. Manageability Considerations 


All manageability requirements and considerations listed in [RFC5440] 
apply to PCEP protocol extensions defined in this document. In 
addition, requirements and considerations listed in this section 


apply. 
8.1. Control of Function and Policy 


A PCE or PCC implementation SHOULD allow configuring the PCEP 
security via TLS capabilities as described in this document. 


A PCE or PCC implementation supporting PCEP security via TLS MUST 
support general TLS configuration as per [RFC5246]. At least the 
configuration of one of the trust models and its corresponding 
parameters, as described in Sections 3.4 and 3.5, MUST be supported 
by the implementation. 
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A PCEPS implementation SHOULD allow configuring the StartTLSWait 
timer value. 


PCEPS implementations MAY provide an option to allow the operator to 
manually override strict TLS configuration and allow unsecure 
connections. Execution of this override SHOULD trigger a warning 
about the security implications of permitting unsecure connections. 


Further, the operator needs to develop suitable security policies 
around PCEP within his network. The PCEP peers SHOULD provide ways 
for the operator to complete the following tasks in regards to a PCEP 
session: 


o Determine if a session is protected via PCEPS. 


o Determine the version of TLS, the mechanism used for 
authentication, and the ciphersuite in use. 


o Determine if the certificate could not be verified and the reason 
for this circumstance. 


o Inspect the certificate offered by the PCEP peer. 


o Be warned if the StartTLS procedure fails for the PCEP peers that 
are known to support PCEPS via configurations or capability 


advertisements. 
8.2. Information and Data Models 
The PCEP MIB module is defined in [RFC7420]. The MIB module could be 


extended to include the ability to view the PCEPS capability, 
TLS-related information, and the TLS status for each PCEP peer. 


Further, to allow the operator to configure the PCEPS capability and 
various TLS-related parameters as well as to view the current TLS 
status for a PCEP session, the PCEP YANG module [PCEP-YANG] is 
extended to include TLS-related information. 

8.3. Liveness Detection and Monitoring 
Mechanisms defined in this document do not imply any new liveness 
detection and monitoring requirements in addition to those already 
listed in [RFC5440] and [RFC5246]. 


8.4. Verifying Correct Operations 


A PCEPS implementation SHOULD log error events and provide PCEPS 
failure statistics with reasons. 
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8.5. Requirements on Other Protocols 


Mechanisms defined in this document do not imply any new requirements 
on other protocols. Note that Section 4 lists possible discovery 
mechanisms for support of PCEPS. 


8.6. Impact on Network Operation 


Mechanisms defined in this document do not have any significant 
impact on network operations in addition to those already listed in 
[RFC5440] and on the policy and management implications discussed 
above. 
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